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(54) Method and system for providing interoperability among processes written to execute on 
different operating systems 



(57) An embodiment of the present invention pro- 
vides an efficient and robust way to facilitate interoper- 
ability between two or more processes which were ini- 
tially written to execute on top of two different operating 
systems but instead execute on top of a third operating 
system. Typically, the preferred embodiment begins by 
launching a parent process which was initially written to 
execute on top of a first operating system. The preferred 
embodiment then obtains a context object that imple- 
ments a naming graph for the parent process. The con- 
text object includes bindings between a given set of 
names and an associated set of objects that are specific 
to the first operating system. 

At some point during execution of the parent proc- 
ess, the parent process spawns a child process which 
was initially written to execute on top of a second oper- 
ating system. Next, the parent process instantiates a 
copy of its context object. The parent process then per- 
forms a conlext merge operation which ensures lhal ob- 
ject names used by the second process are interpreted 
relative to a context object associated wi!h the second 
operating system before (or in lieu of) being interpreted 
relative to the context object for the first operating sys- 
tem. 

Once the context merge operation is complete, the 
new context object is passed to the child process and 
execution of the second process begins. System calls 
initiated by the child process will therefore be interpreted 
relative to the name space for the second operating sys- 
tem. In this way two processes which were initially writ- 
ten to execute on top of two different operating systems 
can interoperare while executing on top of yet a third 
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Description 

The present invention relates to a method and sys- 
tem generally in the field of computer program interop- 
erability among processes written to execute on differ- 
ent operating systems. 

More particularly, the present invention relates to 
the field of facilitating interoperability belween two or 
more processes which were Initially written to execute 
on top of two different operating systems but instead ex- 
ecute on top of a third operating system. 

A number of different operating system vendors are 
currently developing new operating systems. A design 
goal for some of these new operating systems is to pro- 
vide interoperability among incompatible legacy appli- 
cations running on top of the new operating system. For 
example, developers of the new Spring operating sys- 
tem from Sun Microsystems would like to provide inter- 
operability between applications written for the Solaris 
1 ,x family of operating systems and tor the Solaris 2.x 
family of operating systems 1 . The problems with fulfil ling 
this design goal are twofold. First, the legacy applica- 
tions are incompatible among themselves if they were 
written to run on top of different legacy operating sys- 
tems.. For example, a wordprocessing program written 
to run on top of the Solaris 2.4 operating system may 
be unable to interact with a spreadsheet program written 
to run on top of the Solaris 1 .0 operating system. There- 
fore, a user of these application programs would be un- 
able to create a compound document, such as a sales 
report, which included textf rom the wordprocessing pro- 
gram and spreadsheet cells from the spreadsheet pro- 
gram.' 

Second, the legacy applications are incompatible 
with the new operating system because they were not 
written to run on top of the new operating system. There- 
fore, without further improvements, the legacy applica- 
tions would be unable to run on top of the new operating 

This incompatibility causes concern among users 
because users want seamless interoperability between 
their application programs. Users do not want to con- 
cern themselves with the details of compatibility and In- 
compatibility at the operating system level. Likewise, 
such incompatibility concerns operating system devel- 
opers because the inability of an operating system to 
provide interoperability among application programs ad- 
versely impacts the marketability of the new operating 
system. 

To overcome these problems the developers of the 
present invention provide functionality in the new oper- 
ating system to allow incompatible legacy applications 
to interact when executing on top of the new operating 
system. 

An example using Figures 1 A and 1 B will help illus- 
trate why applications written to run on top of different 
legacy operating systems are incompatible with one an- 
other and with the new operating system. Figure 1A il- 



lustrates a first application program which runs on top 
of a first operating system. The' computer system 1 00 of 
Figure 1 A includes a computer 101 , a memory 103, a 
processor 105, and an interface 107. The memory 103 
s includes a first application program 109 and a first op- 
erating system 111 . To accomplish its functions, the first 
application program 1 09 makes calls to the first operat- 
ing system 111 in a format compatible with the first op- 
erating system's application programming interface 
10 ("API"). The API is an abstract interface to the services 
and protocols offered by an operating system. The API 
usually provides a set of function calls which an appli- 
cation invokes to gain access to the operating system's 
services. The first operating system 111 accepts these 
15 calls from the first application program 109, parses the 
calls to determine what system resource(s) need to be 
accessed in order to perform the function, performs the 
requestedlunction by accessing the necessary system 
resource (e.g. a file) through a name space 112 associ- 
20 ated with the first operating system, and returns the re- 
sults to the first application program. 

Figure 2 illustrates a typical name space 200 used 
to access directories and files in a computer system. 
The name space 200 provides a mapping (also called a 
25 "binding") between a set of file, names 20 1 and their as- 
sociated directories or files 203. Given a file name 201 
in a name space 200, a user can "resolve" the file name 
to retrieve the associated file or directory (often called 
a context). It is important to note that a given file name 
30 is always interpreted relative to a particular name space. 
For example, a directory named 7sys/bin/ 
ope rating_sy stem," when resolved relative to a name 
space for the first operating system 111 , could refer to 
a directory containing the binaries for the first operating 
3S system. However, when the same name is resolved rel- 
ative to a name space for a different operating system, 
a different directory could be returned. In this way the 
directory names and file names passed along with the 
call to an operating system r only refer to the directories 
40 and files in the name space 'of that operating system. 

Figure 1B illustrates a second application program 
which runs on top of a second operating system. The 
computer 1 1 3 includes a memory 115, a processor 117, 
and an interface 119. The memory 115 includes a sec- 
45 ond application program 121 , a second operating sys- 
tem 1 23, and a second name space 1 24. To accomplish 
it's functions, the second application program 121 
makes calls to the second operating system 123 in a 
format compatible with the second operating system's 
so API. The second operating system 123 accepts these 
calls from the second application program 121, per- 
forms the requested function by accessing files and di- 
rectories through the second operating system's name 
space 124, and returns the results to the second appli- 
es cation program. 

The API of the first operating system 111 is different 
than and therefore incompatible with the API of the sec- 
ond operating system 123 because it provides a differ- 
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ent set of services and mandates use of a different set 
of interfaces than the API of the second operating sys- 
tem: Similarly, the name space 1 1 2 of the first operating 
system 111 -is different than and therefore incompatible 
with the name space 124 associated with the second 
operating system 1 23 because it provides different bind- 
ings between directory or file names and the directories 
or files themselves. 

This incompatibility problem can be addressed in at 
least two different ways. First, independent software 
vendors can "port" their application programs to the new 
operating system. While this solution is desirable, due 
to the cost of porting an application to a new platform 
this solution is not always viable. The developers of the 
present invention have therefore provided functionality 
in the new operating system to allow incompatible leg- 
acy applications to interact when executing on top of the 
new operating system. 

SUMMARY OF THE INVENTION 

An embodiment of the present invention provides 
an efficient and robust way to facilitate interoperability 
between two or more processes which were initially writ- 
ton to execute on top of two different operating systems 
but instead execute on top of a third operating system. 
Typically, the preferred embodiment begins by launch- 
ing a parent process which was initially written to exe- 
cute on top of a first operating system. The preferred 
embodiment then obtains a context object that imple- 
ments a naming graph for the parent process. The con- 
text object includes bindings between a given set of 
names and an associated set of objects that are specific 
to the first operating system. 

At some point during execution of the parent proc- 
ess, the parent process spawns a child process which 
was initially written to execute on top of a second oper- 
ating system. Next, the parent process instantiates a 
copy of its context object. The parent process then per- 
forms a context merge operation which ensures that ob- 
ject names used by the second process are interpreted 
relative to objects from a context object associated with 
the: second operating system before (or in lieu of) being 
interpreted relative to objects from the context object for 
the first operating system. 

The new context object is then passed to the child 
process and execution of the second process begins. 
Therefore, system calls initiated by the child process will 
first be interpreted relative to the name space for the 
second operating system. The child process can further 
create other child processes designed to execute on 
other operating systems. In this way two processes 
which were initially written to execute on top of two dif- 
ferent operating systems can interoperate while execut- 
ing on top of yet a third operating system. 

The present invention will now be further described 
by way of example, with reference to the accompanying 
drawings, in which:- 



Figure 1A illustrates a first application program 
which runs on top of a first operating system 

Figure 1B illustrates a second application program 
which runs on top of a second operating system. 
s Figure 2 illustrates a name space used to access 
directories and files. in a computer system. 

Figure 3 is a block diagram of a computer system 
for practicing the preferred embodiment of the present 
invention. 

10 Figure 4 is a block diagram of a context object. 

Figure 5 is a block diagram of the context object af- 
ter a context merge method has finished executing. 

Figure 6 graphically illustrates a per-process con- 
text object. 

75 Figure 7 illustrates the context object of a parent 
process. 

Figure 8 is aflow diagram of a Native OS procedure. 
Figure 9 is aflow diagram of a Create Process pro- 
cedure. 

20 Figure 10 is a flow diagram of a Generate Context 
Object procedure. 

Figure 11 illustrates the context object of a child 
process. 

25 DESCRIPTION OF THE PREFERRED EMBODIMENT 

Overview Of The Preferred Embodiment 

A preferred embodiment of the present invention 

30 provides an improved method and system that facili- 
tates interoperability between two or more processes 
which were initially written to execute on top of two dif- 
ferent operating systems but instead execute on top of 
a third operating system. Typically, the preferred em- 

ss bodiment begins by invoking a parent process which 
was initially written to execute on top of a first operating 
system. During process invocation, the preferred em- 
bodiment obtains a context object that implements a 
name space (or, more precisely, a naming graph) for the 

40 parent process. The context object includes bindings 
between a given set of names and an associated set of 
objects that are specific to the first operating system. 
For example, the context object could include a binding 
between the name "/sys/bin" and the object which im- 

45 plements a directory containing the binary files for the 
first operating system. 

At some point during execution of the parent proc- 
ess it spawns a child process which was initially wriUen 
to execute on top of a second operating system. To allow 

so the parent process to successfully spawn the child proc- 
ess, and to allow the child process to/execute on top of 
the third operating system, the. preferred embodiment 
performs the following steps. First, the parent process 
instantiates a copy of its context object. Since the child 

ss process was initially written to run on lop of the second 
operating system and not the first operating system, the 
child process needs to have bindings in its name space 
which are specifically associated with objects in the sec- 
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ond operating system. Therefore, the parent process 
performs a context merge operation (discussed in more 
detail below), which ensures that object names used by 
the second process are interpreted relative to objects 
from a context object for the second operating system 
before (or in lieu of) being interpreted relative to objects 
from the context object for the first operating system. 

Once the context merge operation is complete, the 
new context object is passed to the child process and 
execution of the child process begins. In this way, sys- 
tem calls initiated by the child process will first be inter- 
preted relative to the name space for the second oper- 
ating system. Thus, a system call by the child process 
to "Open /sys/bin/operating_system" will "Open" the bi- 
nary files for the second operating system instead of the 
binary files for the first operating system. In this way two 
processes which were initially written to execute on top 
of two different operating systems can interoperate 
while executing on top of yet a third operating system. 

The System For Practicing The Preferred Embodiment 

Figure 3 is a block diagram of a computer system 
300 for practicing the preferred embodiment of the 
present invention. The computer system 300 includes a 
computer 301 , a video display device 303, an input de- 
vice 305, such as a keyboard, mouse, or pointing de- 
vice, a CD-ROM drive 307, and a permanent storage de- 
vice 309, such as a disk drive. 

The computer 301 includes a processing unit 311 a 
random access memory ("RAM") 313, a programmable 
read-only memory ("PROM") 315, and an interface 317 
for enabling communication between the processing 
unit 311 and the RAM 31 3 or the PROM 315. The inter- 
face 317 also facilitates communication between the 
processing unit 31 1 and peripheral devices (e.g., the 
video display device 303, the input device 305, and the 
CD-ROM device 307). 

The computer memory 313 holds a number of 
items, including an operating system 31 9 that is respon- 
sible for controlling the allocation and usage of the sys- 
tem's hardware resources, such as memory 313, 
processing unit 311, and CD-ROM drive 307. The pre- 
ferred operating system is the Spring. operating system 
from Sun Microsystems, Inc., of Mountain View, Califor- 
nia^ 

Overview Of The Spring Operating System 

Spring is a distributed, object-oriented operating 
system. Thus the Spring operating system is based 
around the creation and manipulation of objects. A 
Spring object is an abstraction that is defined by an in- 
terface. An interface is a strongly-typed contract be- 
tween an object and a client of the object. The interface 
specifies a set of operations that may be preformed on 
the object. Underlying the interface is an encapsulated 
set of data and methods which carry out the operations. 



The granularity of Spring objecis spans a wide 
range, from small data-like objects 1o iarge objects such 
as files and print services. The implementations vary 
from libraries, to separate protected servers, to distrib- 
s uted services implemented by multiple servers. 

Unlike traditional operating systems; Spring objects 
are first class objects. Therefore, clienls can manipulate 
objects directly by performing operations on them or' 
passing them as parameters in operations on other ob- 
io jects. Typically, the client of an object is a process. A 
process includes an address space, threads, and other 
system resources. 

In order 1o facilitate the retrieval and manipulation 
of these objects, Spring provides a uniform naming serv- 
75 ice. The Spring uniform naming service permits any ob- 
ject to be bound to any name. The Spring naming serv- 
ice is based on a few fundamental concepts: names, 
contexts, name bindings, the composition of name 
spaces, and context merges. 
20 Names are conventionally represented as strings, 
are usually printable, and usually have some syntax for 
encoding different information by convention. A name is 
said to denote an object. 

Figure 4 is a block diagram of a context object 400. 
2S The context object 400 contains a data table 401- which 
maintains a set of name-to-object associations (also 
called name bindings). In Spring, names have meaning 
only in the context object in which they are used. Thus 
an object may be bound to several different names in 
30 several different context objects at the same time. 

A client of the uniform naming service performs 
naming operations via methods stored In a method table 
403 of the context object 400. For example, the Spring 
context object aliows the client to resolve a name of an 
35 object. Resolving a name on a context object obtains 
the object denoted by the name. The Spring context ob- 
ject' also allows the client to bind a name to an object 
Binding a name to a context object associates a name 
with a particular object. 
40 Name space composition permits one name space 
to be attached to another name space. Context objects 
are often formed in this manner because, like any other 
object in the Spring environment, context objects can 
be bound to a name in a data table of some other context 
■* £ object. By binding one context object together with an- 
other context object it is possible to create a naming 
graph, which is a directed graph with nodes and labeled 
edges, where the nodes with outgoing edges are con- 
texts. Informally, naming graphs and context objects are 
so also referred to as name spaces. In short, Spring pro- 
vides separate, system-supplied name spaces that can 
be composed together, instead of providing a single, 
system-supplied name space, as is traditionally done in 
the UNIX environment. 
55 The context merge method extends the idea of 
name space composition to al low more than one context 
object to be bound to the same name within the same 
context object. Figure 5 is a more detailed block diagram 
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of context object "c" 407 and illustrates that context ob- 
ject "c" 407 is implemented by merging the objects from 
both context object "s" 501 and "t" 503 into context ob- 
ject "c" 407. As Figure 5 illustrates, the object name "x" 
is bound tq both context object "s" 501 and context ob- s 
ject "t" 503. From a user's perspective, however, only 
object "x" 505 exists. To create this perspective for the 
user, the context merge method reorders the objects 
from the underlying context objects "s" 501 and "t" 503. 
For example, assume that context object 501 imple- 10 
ments objects fora first operating system, context object 
"t" 503 implements objects for a second operating sys- 
tem^ and that the process using context object "c" 407 
was initially written to execute on top of the first operat- 
ing system. In such a case the context merge method 
would order the objectsfrom the underlying conlext ob- 
jects" to ensure that name resolutions were performed 
relative to the objects from context object "s" 501 before 
(or in lieu of) being performed relative tothe objects from 
conlext object "1" 503. Hence a name resolution on ob- 
ject name "x"505 would be resolved relative tothe ob- 
ject "x" bound to context object "s" 501.. 

The Spring operating system is typically used on 
computers in a distributed network environment. The 
Spring operating system groups machines into "villag- 25 
es" based on geographical location, security consider- 
ations, administrative convenience and the like. For ex- 
ample, the accounting department of a corporation may 
have a separate village for security reasons. Similarly, 
different facilities in a university may each maintain its 30 
own village.. 

Given, the scalability of context objects in the Spring 
operating, system, context objects are provided at the 
process, machine, and village level. For example, .con- 
text conn position : can be. used to attach the context ob- 35 
jects of the machines in a village togetherto help-create 
a village context object. . 

Figure 6 graphically illustrates a per-process con- 
text object (or, simply, a "process context object"), that 
is customized to access selected contexts of the ma- «o 
chine and village name spaces within which the process 
is executing: The process context object typically con- 
tains private name bindings, shared name spaces, and- 
standard system objects. 

Private name bindings include environment varia- 
bios and program input/output objects (e.g., I/Q context 
object 601). Changes made to private name bindings 
are only visible to ihe process containing those bindings. 

Shared name spaces (i.e., objects shared with oth- 
er processes in the machine and in the village) are typ- so 
ically attached to the process's name space using well 
known names. For example, a "users" context object 
containing the context objects of different users in the 
village may be attached to the process's context object. 
Likewise, the "device" context object containing both pri- ss 
vate and shared devices may also be attached (e.g. . the 
"dev" context object 603). Finally, the context object 604 
for the machine within which the process executes as 



well as the village context object 606 for the village with- 
in which the machine is iocated, are also attached. Any 
changes made to shared name spaces attached to the 
process's context object are visible to all sharing proc- 
esses. 

Context objects of processes alsd have context ob- 
jects that contain system objects such as "sys" which, ' 
for example, may contain executables undera Vsys/bin" 
context object 605 and libraries under a 7syS/lib" con- 
text object 607.. 

The Preferred Method Of The Present Invention . 

An object of the preferred embodiment is to facilitate : 
interoperability between a parent process and a child 
process even, though "the parent process and the child 
process were initially written to run on top of two. distinct 
operating systoms, both of which are different than a na- 
tive operating system. on which 1he processes currently 
run. The preferred . embodiment will be discussed with 
reference to Figure 3 and Figures 7 through 11. 

Certain initial conditions exist before the preferred 
embodiment executes on the computer. 301.. First, the 
system 300 .is booted and running on top 'of the native 
operating system 319. in addition, .the parent process 
321 has been obtained (e.g., a word processing pro- 
gram written to run under the Solaris 1 .x operating sys- 
tem has been launched). A context object 325 of the par- 
ent process 321 has also been obtained in order to map 
object names generated by the parent process within a 
name space appropriate to the parent process 321 . 

Figure 7. illustrates the context object 325 of the par- 
ent process 321 . The context object 325 includes a data 
table 701 and a method table 703. The data fable 701 
maps object names to their corresponding objects. For 
example, because the parent process 321 was initially, 
written to runbn top of the Solaris 1.x family of operating 
systems, entry 705 in data table 701 first maps the name 
7sys/bin" into objects bound to a context, object ; 707. 
These objects implement the binary files for the Solaris 

1. x family of operating systems. Only if the name being 
resolved is not bound to an object from the. context ob- ; 
ject 707 does entry 705 examine objects bound to con- 
text object 70B. The bindings in context object 708. map. 
names, to objects implementing the binary files for the 
Solaris 2.x family of operating systems, In this way the 
parent process is able to Invoke objects from the Solaris 

2. x operating system, even though the parent process 
was initially written to run on lop of Solaris 1.x. Similarly, 
entry 709 first maps the narme'Vsys/lib" into objects from 
a context object 711 . These objects contain libraries for 
the Solaris 1 .x family of operating systems. Only if the 
name being resolved is not bound to an object from the 
context obj ect 7 1 1 . does ent ry 709 examine objects from 
a context object 712. Objeds from context object 712 
implement the library files for the Solaris 2.x family of 
operating systems. 

Once the initial conditions have been satisfied, the 
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parent process is free to send requests to the native op- 
erating system 319. Figure 8 is a flow diagram of the 
Native OS procedure which carries out requests from 
processes in the system 300. While the native operating 
system 31 9 actually performs a myriad of operations in 
the system 300, for clarity, oniy the operation to create 
a new process is discussed in detail herein. In step 801 
the native operating system receives inputfromthe sys- 
tem 300. In step 803 the native operating system 319 
determines whether the input was an "invoke process" 
request, if the input was an "invoke process" request 
then processing continues with step 805. 1 n step 805 the 
native operating system 319 calls the Create Process 
procedure 327. The Create Process procedure allo- 
cates address space for the process, generates threads 
for the process, and generates a context object which 
embodies a name space lor the process. Upon return 
from the Create Process procedure, processing contin- 
ues in step 801 . 

If the input was not an invoke process request Ihen 
in step 807 the native operating system 319 performs 
normal processing. For example, if an exit request was 
received, the native operating system 319 would end 
processing in the computer 301 . 

Figure 9 is a flow diagram of the Create Process 
procedure. In 1 step 901 the Create Process procedure 
obtains the system resources needed to implement a 
process. For example, the Create Process procedure 
typically obtains an address space in the memory 313, 
generates one or more threads, and maps any code as- 
sociated with the process into the process's address 
space: In step 903 the Create Process procedure calls 
ths Generate Context Object procedure which gener- 
ates a new context object for the new process. Upon 
return from step 903, the new context object is sent to 
the child process in step 905. 

Figure 1 0 is a flow diagram of the Generate Context 
Object procedure which creates a context object for a 
process. For example, the Generate Context Object 
procedure may be called by the parent process 321 to 
create the context object 329 for the child process 323. 
: '"■ In step 1001 the Generate Context Object proce- 
dure instantiates a copy of the context object 325 of the 
parent process 321 . A copy of the parent's context ob- 
ject 325 is instantiated in step 1001 because the child 
' process either uses a copy of the parent's context object 
as its own context object or the parent's context object 
is used as the foundation for building the context object 
329 of the child process 323. 

s Once a copy of the parent's context object has been 
instantiated, processing in the Generate Context Object 
procedure takes one of two paths, depending on a com- 
' piarison of a "process type" of the child process with a 
"process type" of the parenl process (step 1003). A 
; "process type"' indicates which operating system the 
process was initially written to run on top of: For exam- 
: pie, if the parent process 321 was initially written to ex- 
ecute on top of the Solaris 1.x operating system then 



the "process type" of the parent process is "Solaris 1 .x. 
". The "process type" of a process is preferably stored 
in a header section of a file which stores code used to 
generate the process. For example, the file which stores 
5 the code used to implement a spreadsheet program typ- 
ically includes a header section which contains "process 
type" information for the spreadsheet program. If the 
comparison indicates that the child process 323 and the 
parent process 321 were both initially written to run on 
to top of the same operating system (e.g., the Solaris 1.x 
operating system) then the child process 323 is fully 
compatible with the parent process' context object 325 
and, therefore, just uses the copy of the parent's context 
object as its own context object 329. An example may 
15 help illustrate this compatibility between the child proc- 
ess and the parent process. If the child process 323 in- 
vokes a library function using the name "/sys/fib" then 
the child process 323 will expect to retrieve a function 
from the Solaris 1.x library. By resolving the name "/sys/ 
20 lib" relative to a copy of the context object 325 of the 
parent 321 , the context object 711 (Figure 7} containing 
the libraries of the Solaris operating system 1 .x is ac- 
cessed. In this way, the appropriate object from the So- 
laris 1.x library is returned to the child process 323 for 
25 further processing. 

If the comparison indicates that the child process 
323 and the parent process 32i were both written to run 
on top of two different operating systems (e.g. the So- 
laris 1 ,x operating system and the Solaris 2.x operating 
30 system) then the child process 323 is not fully compat- 
ible with the context object 325 of the parent process 
321 . This incompatibility can also be seen by way of ex- 
ample using Figure 7.- Assume that the child process 
323 invokes a request to resolve a name containing the 
35 string Vsys/lib" or "/sys/btn". Also assume that the child 
process 323 is resolving the name relative to a copy of 
the context object 325 of the parent process 321 . In" this 
case the child process 323 will receive an object from 
the name space of the Solaris 1 .x operating system. The 
40 child process 323 instead needs access to objects con- 
taining binaries or libraries of the Solaris 2.x operating 
system. To provide the child process 323 with access to 
the appropriate objects in the Solaris 2.x name space, 
the Generate Context Object procedure, in step 1005, 
45 invokes a context merge method 715 (Figure 7). The 
context merge method 715 orders the context objects 
so that the objects most appropriate to the child process 
are accessed first when resolving an object name. 
To accomplish this the context merge method 715 
so first determines the "process type" of the child process 
323. The process type indicates the operating system 
the process was initially written to run on lop of. The 
process type of the child process 323 is the Solaris 2!x 
operating system. Next, the context merge method 715 
ss determines the' process type of the parent process 321 . 
The process type of the parent process 321 is the So- 
laris 1 .x operating system. Given the process type of the 
parent process and the process type of the child proc- 
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ess, the context merge method determines what infor- 
mation in the data table 701 needs to be modified in or- 
der to fully support the child process 323. The needed 
modifications are dependent on the process types of the 
context objects being merged. 

Figure 11 illustrates the modifications made to the 
(Solaris 1 .x) context object 325 in order to provide full 
compatibility to the (Solaris 2.x) context process 323. 
First, the context merge method 71 5 modifies entry 705 
of the data table 701 to indicate that a context merge 
operation has been performed on the object name "/sys/ 
bin". The preferred syntax for indicating that the context 
merge operation. has been performed on an entry uses 
the symbol followed immediately by an identifier. For 
example, the context merge method modifies entry 705 
to read 7sys/bin=Solaris 2.x:: Solaris 1.x" to indicate 
that the name 7sys/bin" is first resolved relative to ob- 
jects from acontext object 708 containing binaries of the 
Solaris 2.x operating system. Only if the name 7sys/bin" 
is not bound to objects in context object 708 are objects 
from context object 707, containing binaries of the So- 
laris 1.X operating system, examined. The context 
merge method 71 5 makes similar modifications 1o entry 
709 to indicate that the name Vsys/lib" is resolved rela- 
tive to objects from a context object 712 for libraries of 
the Solaris 2.x operating system before (or in lieu of) 
resolving the name relative to objects from context ob- 
ject 711 containing libraries of the Solaris 1 .x operating 
system. 

After the generate context object procedure com- 
pletes the context merge operation in step 1005 of Fig- 
ure 10, processing continues in step 905 of the Create 
Process procedure (Figure S). In step 905 the Create 
Process procedure sends the context object 329 to the 
child process 323. 

Once the child process 323 receives the context ob- 

. ject 329, the child process can safely perform any of its 
operations because the object names contained in the 
operation requests will be resolved relative to objects 
from the appropriate context object. In this way, a parent 
process written to execute on top of a first operating sys- 
tem, can spawn a child process written to execute on 

, top of a second operating system, while both the parent 
process and the chiid process are actually executing on 
top of yet a third operating system. 

Although the present invention has been described 
in terms of a preferred embodiment, i1 is not. intended 
that the invention- be limited to this embodiment. Modi- 
fications within the spirit of the invenlion will be apparent 
to those skilled in the art. 

Those of ordinary skill wil! understand that the 
teachings of the present invention could be coupled with 
the use of symbolic links to map more abstract names 
into the entries of the data table 701. For example, while 
data entry 705 was described as containing the name 7 
sys/bin", a symbolic link could be used to first map the 
name "/bin" into the table entry 705 for "/sys/bin " In ad- 
dition, the entry 705 could then be linked to yet another 



entry in the table corresponding to a particular type of 
operating system. For example, the entry "/sys/bin" 
could .be mapped into an entry for 7 Solaris 1.x" which 
contains a linktothe.context object containing the. bina- 
5 ries for the Solaris 1.x operating system. 

While the examples above discuss instantiating a 
copy of the. parent's context object in order to obtain the 
child's context object, those of ordinary skill will under- 
stand that optimizations of this method are possible. For 
10 example, another embodiment of the present invention 
statically generates preferred context objects for each 
non-native operating system which the native operating 
system supports. A server preferably stores each pre- 
ferred conlexl object When a child process needs a con- 
's text object, the appropriate context object is retrieved 
from the server. 

Finally while the examples set forth above discuss 
facilitating interoperability between, two processes in- 
tended to run on two different operating systems, those 
20 of ordinary skill will understand that the techniques dis- 
cussed herein can be extended to facilitate interopera- 
bility between "N" processes intended to run on "N" dif- 
ferent operating systems. These and other modifica- 
tions will be apparent to those skilled in the art. 

25 

Claims 

1. A method executed in a computer system which fa- 
30 cilitates interoperability between processes which 

were designed to execute on different operating 
systems, the computer system including a proces- 
sor and a memory, the computer system also includ- 
ing one or more context objects, each context object 
35 maintaining: bindings between object names and 

their associated object implementations, wherein 
an associated object implementation can itself be 
another context object, the method comprising the 
steps of: 

40 under control of a first operating system, 

invoking a parent process which was designed 
to execute on a second operating system; 
obtaining for the parent process a context ob- 

45 . ject which itself bindsat least one context ob- 

ject associated with the second operating sys- 
tem to a selected object name; . 
during executionof the parent process, launch- 
ing a child process which was designed to ex- 

50 ecute on a third. operating system; 

obtaining a context object for the child process 
which includes substantially the same name 
bindings found in the context object for the par- 
ent process; 

55 performing a context merge operation on the 

context object of the child process; and 
in response to performing the context merge 
operation, resolving the selected object name 
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on the context object for the child process by 
accessing objects from a context object asso- 
ciated with the third operating system before 
accessing objects from trie context object as- 
sociated with .the second operating system. s 

The method of claim 1 wherein the step of perform- 
ing the context merge operation further includes 
generating. a hew conlext object which includes all 
objects from the context objects for the second op- 10 
erating system and the third operating system. 

The method of claim 2 wherein the objects are or- 
dered so that the step of resolving the' selected ob- 
ject name. accesses objects from the context object 15 
associated with the third operating system before it 
accesses objects from the context object. associat- 
ed with the second operating system. 

The method of claim 1 wherein the step of perform- 2° 
ing the context merge operation further includes 
creating a link between the selected object name 
. and the context objects for the second operating 
system and the third operating system. 

25 

. The method of ciaim 4 wherein the Sink indicates 
that the selected object name should be resolved 
relative to the context object for the third operating 
system before being resolved relative to the context 
object for the second operating system. 30 

The method of claim 4 wherein the link is imple- 
mented as a list data structure and wherein the step 
. of performing the context merge operation further 
includes the step of moving the context object for 35 

. the third operating system to a first position in the 

. list. 

The method of claim 1 wherein the step of perform- 
ing the context merge operation further includes in- " 40 
■sailing the context object for the third operating sys- 
tem into a first position of a list data structure, 
wherein the list data structure associates the select- 
ed object name with one or more. context objects 
which resolve the selected object name. 45 

The method of claim 1 wherein the step of obtaining 
trie context objectforthe child process includes the 
step of invoking a duplicate function which resides 
in the context object of the parent process. 50 

The method of claim 1 wherein the step of obtaining 
the context object for the child process includes the 
' steps of sending a request to a server which stores 
a pre-processed context object for the child process 
and receiving the requested context object from the 
server. 



10. The method of claim 1 wherein the child process 
invokes an object from the context object for the 
second operating system by resolving an object 
name in the context object for the second operating 
system. 

11. The method of claim 1 wherein the parent process 
invokes an object from the context object for the 
third operating system by resolving an object name 
in the context object for the third operating system. 

12. A method executed in a computer system which fa- 
cilitates interoperability between processes which 
were designed to execute on different operating 
systems, the computer system including a proces- 
sor and a memory, the computer system including 
one or more context objects, each context object 
maintaining bindings between object names and 
their associated object implementations, wherein 
an associated object implementation can itself be 
another context object, the computer system also 
includes a parent process which was designed to 
execute on a first operating system, the method 
comprising the steps of: 

under control of a second operating system, 

receiving a request from the parent process to 
launch a child process which was intended to 
execute on a third operating system; 
launching the child process; 
obtaining a context object for the child process; 
performing a context merge operation on the 
context object for the child process; and 
in response to performing the context merge 
operation, resolving a selected object name on 
the context object for the chiid process by ac- 
cessing objects from a context object associat- 
ed with the third operating system. 

13. A method executed in a computer system which fa- 
cilitates interoperability between processes which 
was designed to execute on different operaling sys- 
tems, the computer system including a processor 
and a memory, the computer system including one 
or more context objects, each context object main- 
taining bindings between object names and their 

. associated object implementations, wherein. an as- 
sociated object implementation can itself be anoth- 
er context object, the computer system also includ- 
ing a parent process which was designed to exe- 
cute on a first operating system, the method com- 
prising the steps of: 

providing a first mechanism for receiving a re- 
quest from the parent process to launch a child 
process which was intended to execute on a 
third operating system; 

providing a second mechanism for launching 
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the child process; 

providing a third mechanism for obtaining a 
context object for the child-process; 
providing a fourth mechanism for performing a 
context merge operation on the context object 
for the child process; and 
providing a fifth mechanism, responsive to per- 
forming the context merge operation, for resolv- 
ing a selected object name on the context ob- 
ject for the child process by accessing objects 
from a context object associated with the third 
operating system. 

1 4. A method executed in a computer system which fa- 
cilitates interoperability between processes which 
were designed to execute on different operating 

: systems, the computer system including a proces- 
sor and a memory, thecomputersysiem also includ- 
ing on e or more context objects, each context object 
maintaining bindings between object names and 
their associated object implementations, wherein 
an associated object implementation can itself be 
another, context object, the method comprising the 

providing a first operating system for, 

invoking a parent process which was designed 
to execute on a second operating system; 
obtaining for the parent process a context ob- 
ject which itself binds si least one context ob- 
ject associated with the second operating sys- 
tem to a selected object name: 
during execution of the parent process, launch- 
ing a child process which was designed to ex- 
ecute op a third operating system; 
obtaining a context object for the child process 
which includes substantially the same name 
bindings found in the context object for the par- 
ent process; 

performing a context merge operation on the 
context object of the child process; and 
in response to performing the context merge 
operation, resolving the selected object name 
on the context object for the child process by 
accessing objects from a context object asso- 
ciated with the third operating system before 
accessing objects from the context object as- 
sociated with the second operating system. 

15. A computer system for facilitating interoperability 
between processes which was designed to execute 
on different operating systems, the computer sys- 
tem including a processor and a memory, the com- 
puter system including one or more context objects, 
each context object maintaining bindings between 
object names and their associated object imple- 
mentations, wherein an associated object imple- 
mentation can itself be another context object, the 



system comprising: 

a first operating system configured to control, 

a first program mechanism configured to invoke 
a parent process which was designed to exe- 
cute on a second operating system; 
a second program mechanism configured to 
obtain for the parent process a context object 
which itself binds at least one context object as - 
. sociated with the second operating system to a 
selected object name; 

a third program mechanism configured to start 
a child process which was designed to execute 
on a third operating system; 
a fourth program mechanism configured to ob- 
tain acontext object for the child process which 
includes the same name bindings found in the 
context object for the parent process; 
a fifth program mechanism configured to per- 
form a context merge operation on the context 
object of the child process; and 
responsive to the context merge operation, a 
sixth program mechanism configured' to re- 
solve the selected object name on the context 
object for the child process by accessing ob- 
jects from a context object associated with the 
third operating system before accessing ob- 
jects from the context object associated wilh 
the second operating system. 

16. The system of claim 15 wherein the fifth program 
mechanism includes a seventh program mecha- 
nism configured to generate a new context object 
which includes all objects from the context objects 
for the second operating system and the third oper- 
ating system. 

17. The system of claim 16 wherein the objects in the 
new context object are ordered so that t he sixth pro- 
gram mechanism accesses objects from the con- 
text object associated with the third operating sys- 
tem before if accesses objects from the context ob- 
ject associated with the second operating system. 

18. The system of claim 15 wherein the fifth program 
mechanism further includes a seventh program 
mechanism configured to create a' link between the 
selected object name and the context objects for the 
second operating system and the third operating 
system. 

19. The system of claim 18 wherein the link indicates 
that the selected object name should be resolved 
relative to the context object for the third operating 
system before being resolved relative to the context 
object for the second operating system. 

20. The method of claim 18 wherein the link is imple- 
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mentsd as a list data structure and whsrein the fifth 
program mechanism further includes an eight pro- 
gram mechanism configured to move the context 
object for the third operating system to a first posi- 
tion in the list. 



21. The system of claim 15 wherein the fifth program 
mechanism invokes a seventh program mechanism 
configured to insert the context object for the third 
operating system into a first position of a list data 10 
structure, wherein the list data structure associates 
the selected object name with one or more context 
objects which resolve the selected object name. 

22. The system of claim 15 wherein the sixth program 16 
mechanism includes a seventh program mecha- 
nism configured to invoke a duplicate function 
which resides in the context object of ihe parent 
process. 

20 

23. The system of claim 15 wherein the sixth program 
mechanism includes a seventh program mecha- 
nism configured to send a request to aserver which 
stores a pre-processed context object for the child 
process and to receive the requested context object 26 
from the server. 



24. A computer system which facilitates interoperability 
between processes which was designed to execute 
on different operating systems, the computer sys- 
tem including a processor and a memory, the com- 
puter system including one or more context objects, 
each context object maintaining bindings between 
object names and their associated object imple- 
mentations, wherein an associated object imple- 
mentation can itself be another context object, the 
computer system also including a parent process 
which was designed to execute on a first operating 
system, the system comprising: 

a second operating system configured to con- 

: trol, 



a first mechanism configured to receive a re- 
quest from the parent process to. jaunch a child 
process which was designed to execute on a 
third operating system; 

a second mechanism configured to launch the 
child process;. 

a third mechanism configured to obtain a con- 
text object for the child process; . 50 
a fourth mechanism configured to perform a 
context merge operation on the context object 
of the child process; and 

a fifth mechanism, responsive to the fourth 
mechanism and configured to resolve a select- 55 
ed object name on the context object of the 
child process by accessing objects from a con- 
text object associated with the third operating 
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(57) An embodiment of the present invention pro- 
vides an efficient and robust way to facilitate interoper- 
ability between two or more processes which were ini- 
tially written to execute on top of two different operating 
systems but instead execute on top of a third operating 
system. Typically, the preferred embodiment begins by 
launching a parent process which was initially written to 
execute on top of afirst operating system. The preferred . 
embodiment then obtains a context object that imple- 
ments a naming graph for the parent process. The con- 
text object includes bindings between a given set of 
names and an associated set of objects that are specific 
to the first operating system. 

At some point during execution of the parent proc- 
ess, the parent process spawns a child process which 
was initially wrillen to execute on top of a second oper- 
ating system. Next, the parent process instantiates a 
copy of its context object. The parent process then per- 
forms a context merge operation which ensures that ob- 
ject names used by the second process are interpreted 
relative to a context object associated with the second 
operating system before (or in lieu of) being interpreted 
relative to the context object for the first operating sys- 

Once the context merge operation is complete, the 
new context object is passed to the child process and 
execution of the second process begins. System calls 
initiated by the child process will therefore be interpreted 
relative to the name space for the second operating sys- 



tem. In this way two processes which were initially writ- 
ten to execute on top of two different operating systems 
can interoperare while executing on top of yet a third 
operating system. 
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